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The Null Packet 


Abstract 


The ever-elusive Null Packet received numerous mentions in documents 
in the RFC series, but it has never been explicitly defined. This 
memo corrects that omission. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6592. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


Null Packets are neither sent nor acknowledged when not received. 
They are perfect in their simplicity and they are very true, as they 
extrapolate from the twelfth Truth of networking [RFC1925]: there is 
*literally* nothing left to take away. 


An early mention of the Null Packet is attributed to Van Jacobson in 


the context of TCP/IP Header Compression [RFC1144]. Mind you, the 
Null Packet is not created by compressing a packet until it 
disappears into nothingness. Such a compression scheme might not be 


reversible; instead, Section 3.2.4 of [RFC1144] describes an explicit 
lack of response as "Nothing (a null packet) is returned". 


Many documents attempt to define in-the-wire code points and protocol 
identifiers (PIDs) for a Null Packet [RFC4259] [RFC4571] [RFC5320]. 
However, such an exercise is futile. This memo postulates that a 
Null Packet cannot have a PID, as the existence of a protocol 
construct or value would null the null; this includes the inability 
to use 0x0, 0x0000, or even 0x00000000, but excludes the restriction 
to use "" (see Section 2.1). 


An IPv6 Next Header value of 59 (No Next Header) (see Section 4.7 of 
[RFC2460]) does not create a Null Packet. 


2. The Null Packet 


The Null Packet is a zero-dimensional packet. The Null Packet exists 
since it is non-self-contradictorily definable. 
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2.1. Formal Definition 


[This section is intentionally left blank, see also Section 0 of 
[NULL] .] 


2.2. Faux Amis 


Many experts naively confuse the Null Packet with an Imaginary 
Packet, in a rationalization attempt when faced with the inability to 
prove the existence of the Null Packet. For reference, an Imaginary 
Packet contains the IP Version of 4i or 6i. However, protocol 
purists are not fooled and quickly plea with experts to get real. 


The Null Packet’s qualities should not be confused with the bit- 
bucket blackhole nature of the null device, since the Null Packet 
does not discard packets. Confusion might stem from the fact that 
the behavior is similar to that of input streams reading from /dev/ 
null (i.e., "nothing is returned"). 


3. Performance Metrics Considerations 


A protocol sending Null Packets effectively sends packets of zero 
length. One characteristic of flow streams of Null Packet traffic is 
that increasing the rate at which Null Packets are sent does not 
increase the bit rate of the Null Packet traffic. The bit rate 
continues being unequivocally null, unless an infinite number of Null 
Packets per unit of time could be sent. Similarly, should a user 
stop sending Null Packets, the bit rate of Null Packets would not 
vary. Traditional traffic performance metrics are not well suited to 
qualify Null Packet traffic; this fact argues for the creation of new 
sets of performance metrics that test positive for "usefulness" (see 
Section 5.2 of [RFC6390]). 


4. Security Considerations 


When used in a Multiprotocol Label Switching (MPLS) environment, the 
Null Packet can only use an Implicit NULL label (see Section 4.1.5 of 
[RFC3031]. The Implicit NULL label is a label that can be 
distributed, but which never actually appears in the encapsulation. 
The Nil FEC is not used. 


The security considerations for the Null Packet are undefined, as 


hereby described. The "good" nature of Null Packets is quite 
useless, and the "bad" nature of Null Packets is rather inefficient. 
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4.1. The Paradoxical Firewall 


Many firewalls and other security devices have trouble identifying 
the Null Packet. Others claim to filter out Null Packets quite 
effectively and effortlessly. Interestingly, or not, both might be 
correct, which begs the omnipotence paradox: Can a firewall create a 
rule to filter out the Null Packet coming from the "outside", and not 
see Null Packets being allowed on the "inside"? 


4.2. The Null Packet is Good 


The Null Packet cannot have the Evil Bit ("E") [RFC3514] set, by 
definition (see Section 2.1). Consequently, it is rather clear and 
undeniable that the Null Packet is harmless, having no evil intent. 


4.3. Just Encrypt It, Carefully 


A commonly accepted practice for Security Considerations sections is 
to wrap a blanket "encrypt around foo" statement, for almost any 
value of "foo". This document is no exception. However, surgical 
care must be taken to not apply NULL encryption [RFC2410] to the Null 
Packet; such a careless act can bring discontinuities and "Oops" more 
epic than dividing by zero or Googling the word "Google" (it has been 
rumored that such action can break the Internet, although this can be 
easily disproved by reductio ad absurdum.) 


4.4. Denial of Denial of Service 


Even when sysadmins, netadmins, secadmins, and other NOC engineers 
are faced with the undisputed inability to block Null Packets (see 
Section 4.1), attacks leveraging Null Packets are not quite so common 
in the wild and are not seen in the seek*Wsecurity news. Perhaps 
because these unusual packets are hard to spoof in the data plane, or 
because their Time to Live (TTL) or Hop Limit cannot be altered since 
it does not exist [RFC5082], the fact is that Null Packets present a 
denial of denial of service (DoDOS). 


An important corollary is that dropping Null Packets does not 
generate packets. 


5. IANA Considerations 


This document explicitly and emphatically, yet very humbly, requests 
IANA to not create an empty registry for the Null Packet. 
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